近日，WhiteSource 公司发布《2019年开源组件安全漏洞现状报告》。奇安信代码卫士团队编译如下：开源组件已成为当前软件应用程序不可或缺的一部分——如果没有它们，则无法跟上发布周期的快速步伐。随着对开源组件的使用数量和开源安全研究工作不断增多，2019年已发布开源安全漏洞的数量创新高。
本研究报告聚焦开源安全最薄弱以及最强大之处，以期对已知开源安全漏洞快速而复杂的变化做出一些澄清。在本报告中，我们将关注2019年已发布的开源漏洞数量，之后进一步分析流行编程语言中的开源安全漏洞、多年来最常见的 CWE、开源漏洞的评分和严重性、以及备受青睐的最流行的开源项目中的漏洞情况。
根据WhiteSource 公司从 NVD、数十份安全公告、同行漏洞数据库和流行开源问题追踪器采集的数据来看，2019年已披露的开源软件漏洞的数量急剧增长到6000余个已报告漏洞。随着近几年来开源组件的广泛使用、开源社区的大幅增加以及媒体对数据泄露事件的披露，人们对开源安全也越发重视。2019年，已报告的开源漏洞的数量增长了近50%。
近几年来，科技巨头大力投入以更好地保护和管理开源项目的安全，而开源社区也致力于开展安全研究工作以公布新发现的开源安全漏洞及其修复方案。修复方案将通常是更新现有版本或为易受攻击代码打补丁。超过85%的开源安全漏洞在披露时已具有修复方案。遗憾的是，用户并不一定总是能从开源社区所做的这些努力中获益。仅有84%的已知开源漏洞出现在 NVD 中。开源漏洞信息并未集中发布在某处，而是散见于数百个资源，且有时候信息索引不友好，使得人们难以搜索某些具体数据。虽然45%的已报告开源漏洞最初并未报告给 NVD，但很多在其它资源中报告数月后最终发布于 NVD 中。从 WhiteSource 数据库来看，仅有29%的源自 NVD 以外资源的开源漏洞最终发布于 NVD。
鉴于开源组件的使用数量以及安全研究工作都在继续增长，已报告开源漏洞的数量将继续增加。另外，我们看到，开源社区正在寻找解决开源安全流程混乱问题的新方法。其中一个例子就是 GitHub 推出的 Security Lab，它旨在帮助研究人员、开源项目维护人员和用户更容易地以安全的方式报告疑似漏洞，而非将 0day 漏洞公之于众。GitHub 的这种嵌入式披露流程将鼓励开源项目维护人员正确地报告漏洞，而非仅仅推出修复方案。使维护人员自己报告漏洞将带来更高质的元数据如受影响版本和已修复版本，这和第三方报告漏洞的情况截然不同。我们担忧的是，虽然这些工具将有助于正确地报告漏洞，但也很有可能使当前的问题恶化，毕竟软件开发人员已经疲于追赶不断增长的已报告开源漏洞。
看到2019年急剧增长的开源漏洞数量，我们不禁想要了解几大编程语言中的开源漏洞数量的变化趋势是否一致？为此，我们对比了7大编程语言中存在的2019年已报告开源漏洞的数量，并将其与过去十年的情况进行对比。每种语言中的开源漏洞数量（2019年与2009-2018年）
（2009年至2018年期间，C、PHP、Java、JS、C++、Python 和Ruby 中漏洞数量分别占总量的 47%、15%、11%、10%、6%、6%和5%；在2019年期间，该比例分别为30%、27%、15%、10%、9%、5%和5%。可看到，在这两个时间段，C语言中漏洞占比最高，其次是 PHP和Java。C语言的占比相对数量有所下降，而 PHP 和 Java 在增长。Python 虽然流行度增强，但漏洞占比保持不变。C++ 是唯一一个漏洞占比有所下降的语言。）由于使用C语言编写的代码最多，因此C语言中的开源漏洞数量比例仍然最高。然而，随着其它语言的崛起，C语言中开源漏洞的数量继续减少。话虽如此，但PHP语言的漏洞相对数量大幅增长，但其流行程度不可相提并论。Python 的漏洞数量占比相对较低，尽管其流行程度尤其是在开源社区的流行程度持续升高。希望这一结果是由安全编码实践引发的，而非对 Python 项目的安全研究较少导致的。
我们想要分析的另一方面是2019年最常见的漏洞类型。2019年的五大 CWE 和近几年的趋势一致，而且均与信息泄漏相关。令人担忧的问题在于，最常见的 CWE 是因为简单的代码错误和不精确的编码实践造成的，而开发人员只要坚守相当基础的编码标准即可避免它们。
虽然不在前五大榜单中，但有意思的是 CWE-352（跨站点请求伪造）已位列2019年的前十大 CWE 榜单，而 CWE-89（SQL 注入）在继2015年被剔除在前五大榜单之外后再次上榜。这可能是因为开源 web 项目数量增长造成的，它可能表明 web 漏洞也在增长，我们在编写代码时应该格外注意这一点。
在查看几大编程语言中存在的前三大 CWE 时，我们注意到三个 CWE 稳坐所有语言的头把交椅，C语言除外：跨站点脚本漏洞 (XSS)(CWE-79)
信息泄漏/披露 (CWE-200)
输入验证 (CWE-20)
多数语言中最常见的 CWE 有很多是重叠的，这一点并不奇怪。越来越多的研究人员依靠自动化检测工具寻找漏洞，而这类工具易于找到的漏洞类型是XSS 和输入验证问题。
信息泄漏漏洞仍然存在于多数语言的另外一个原因可能是，它涵盖的范围很宽泛，导致多种漏洞很可能被归于该类别。
不断增长的已报告漏洞数量要求开发团队快速确定安全警报的优先级。CVSS 评分通常是决定补救措施优先级的首选参数，但理应如此吗？在过去几年中，CVSS 已更新数次（从 v2 到 v3，最新版本是 v3.1），寄望于实现一种可衡量的客观标准，助力支持所有组织机构和行业。然而，它也改变了高危漏洞的定义。我们查看了2016年至2019年间数万个漏洞及其 CVSS v2、v3.0 和 v3.1 评分，对比过去四年来每个评分版本对漏洞严重程度的评定。从 v2 到v3，最值得注意的变化是，评分大幅提高：某个漏洞在v2 版本的评分是7.6，而在v3.0 中就是9.8。研究团队发现 CVSS v3.0 版本中的高危和严重等级的漏洞数量更多。严重程度划分：CVSSv2.0、CVSSv3.0、CVSSv3.1
当前仍然缺少能够对漏洞进行优先级排序、处置以及全面理解漏洞对项目造成的影响大小的工具。
从新版 CVSS v3.1 评分的严重程度分布来看，我们可看到它的分布并不正常，因为17%的漏洞是“严重”级别，而仅有2%的漏洞是“低危”级别。CVSS v3.x 严重性划分 (2016-2019)
虽然该社区一直致力于找到一种可观的严重程度评分标准，助力用户应对不断发展的安全局势，但该标准尚不完美。导致这种不平衡的因素是人们对高危和严重问题的关注增强，以及创建 CVE 是一种耗时的工作而导致某些人选择忽略低危问题的事实。但问题仍然是：当超过55%的漏洞是高危或严重漏洞时，我们如何期望团队有效地处理漏洞的优先级呢？
深入挖掘开源安全漏洞（按照年份、类型或严重性评分的分布情况）后，我们很容易忘记这些问题实际上存在于所有备受青睐的软件项目中，而这些软件项目碰巧是开源项目。我们来看下我们一直在密切研究的开源安全漏洞影响的开源项目。
这个列表带来的最重要的一点是，仅仅因为流行的开源项目存在漏洞就判定它们天生不安全是不正确的。它只是说明，作为开源项目的用户，我们需要意识到其中的安全风险并确保将开源依赖关系更新至最新状态。开源组件已成为软件项目不可或缺的一部分。开源漏洞局势可能乍看复杂且具有挑战性，但其实存在能够获取开源组件可见性和控制性的多种方法。
https://www.whitesourcesoftware.com/open-source-vulnerability-management-report/#
题图：Pixabay License
本文由奇安信代码卫士编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 www.codesafe.cn”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的产品线。